File EIPS/eip-7773.md

Requires 1 more review from Authors: @adietrichs, @nixorokish, @parithosh, @ralexstokes, @timbeiko
Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @lightclient, @samwilsn, @xinbenlv

Hi @poojaranjan, I will link this eipw (EIP Walidator) issue here, which seems to be the problem here also.

I am not entirely sure here, for the CFId/SFId EIPs I would find it very logical that these have to move to Review before we can move this to review. However, for historical purposes, it would make sense that this meta document /also/ includes all Declined For Inclusions EIPs.

I just realized that this is not possible because this would definitely prevent it from moving to Final. However, for future purposes, if an EIP got declined in this fork it does not necessarily mean it is declined for the next fork, for various reasons. The Fusaka meta EIP also does not have a DFI list and our rule for Finalized EIPs to only ref Finalized EIPs might in some cases not be correct as we might want to include references like "these EIPs were considered but not included" (DFId) or in other contexts: we did these research attempts in the past but did not finish those (EIP would move to Stagnant at some point, or maybe even Withdrawn). To get around this restriction we can likely use backticks like EIP-X, but explicitly marking an EIP-X in text like EIP-X [DRAFT] or somehow indicating that this reference is not meant for any specification or requirement, but rather for historical purposes (or whatever reason).

This would (likely) mean that in order to move this to Review by our EIP rules, all EIPs referenced (so also the DFId ones) have to be in Review or higher. Which will likely result in us deleting the DFI section to enforce our rules, which in this case I am not sure if this is correct.

BTW, to move those EIPs (especially those SFId and also those CFId), you could open these one-line-change PRs yourselves such that the author(s) get a ping and can then improve.

I'll raise this comment to eip-editors as well and propose it for EIPIP#128.

The commit 81edd77 (as a parent of 0f2d351) contains errors.
Please inspect the Run Summary for details.

@jochem-brouwer

I am not entirely sure here, for the CFId/SFId EIPs I would find it very logical that these have to move to Review before we can move this to review.

I agree, this PR has to wait until all CFId/SFId EIPs are moved to Review. At this point, I think it make sense to remove DFI section from this Meta EIP.

However, for historical purposes, it would make sense that this meta document /also/ includes all Declined For Inclusions EIPs.

As much as I agree with the idea, it makes sense to keep the bot restricted and remove DFI from the Meta EIP at some point.

To get around this restriction we can likely use backticks like EIP-X, but explicitly marking an EIP-X in text like EIP-X [DRAFT] or somehow indicating that this reference is not meant for any specification or requirement, but rather for historical purposes (or whatever reason).

I like the idea; however, unsure if the bot can be designed like that. Will be curious to hear what @SamWilsn thinks about updating the bot accordingly.

BTW, to move those EIPs (especially those SFId and also those CFId), you could open these one-line-change PRs yourselves such that the author(s) get a ping and can then improve.

In today’s ACD call, I reminded all authors to submit status change PRs and encouraged them to create those PRs as soon as possible. I’m hoping to receive most of them over the weekend so we can bring all pending status change PRs to the next EIP Editing Office Hour.
If any EIPs are still missing by then, I’ll create the PRs myself and tag the respective authors for review. Hopefully, we have all relevant EIPs moved into Review status before the next ACD call. :)

Just noticed, as per EIP-7723, DFI should not be a part of a Last Call / Final Meta EIP.

Perhaps EIP-7723 could instead specify that the Declined for Inclusion section is removed when the Meta EIP moves to Review, since Meta EIP Review generally corresponds to the Devnet stage. So retaining DFI beyond that point doesn’t appear necessary, except we find a way to keep it for historical purposes.

This is based on the EIP Status vs N/w Upgrade Stage mapping in most Standards Track - Core EIP lifecycle

PFI = Draft or Review
CFI = Review [EIP devnet or Upgrade devnet]
SFI = Review or Last Call [Upgrade devnet or Public Testnet]
Included = Final [Mainnet]

Ah great points, that actually makes sense @poojaranjan 😄

since Meta EIP Review generally corresponds to the Devnet stage.

I am slightly uncomfortable with this though, and also including the "rule" when the EIP moves to Review status, DFI list should be removed. In the "Devnet stage", which I think we are now almost closing (one, maybe two more devnets?), would then remove this DFI list and this would also remove this "sentiment" from the canonical fork Meta:

Declined for Inclusion signals that client developers wish to exclude the EIP from the current network upgrade and stop discussing its potential inclusion or implementation status in relation to this upgrade

However the EIP also states this:

In exceptional circumstances, client developers MAY choose to move an EIP from Declined for Inclusion to Considered for Inclusion or Scheduled for Inclusion.

So a DFId EIP is not a guarantee that it does not go in this fork, although it is a strong one.

My feeling is that it is the point to move the EIP to "Review" once we are in the "final devnet" stage, this would remove the DFId EIPs, but it would create some uncomfortable ambiguity about what this Review status is/signals. I feel like we should make this clear. If a DFId EIP is later re-proposed then via git history we can signal/verify that the EIP was DFId before (but this is not super elegant).

@jochem-brouwer
I agree that the process clarity will be helpful.
The present version of EIP-7723 has done a great job of explaining the upgrade stages and the process. It is now two full upgrade cycles old and is at a point where it could be moved to theFinal status itself. I, however, feel that the present version of EIP-7723 needs some further refinement in the specification section one clear distinction between "status" and "stage", as proposed here, and perhaps more as we finalize exactly when DFI should be removed from the Upgrade Meta EIP. But that’s a discussion for EIP-7723’s "discussion-to" thread and EIPIP meeting.

I am slightly uncomfortable with this though, and also including the "rule" when the EIP moves to Review status, DFI list should be removed. In the "Devnet stage", which I think we are now almost closing (one, maybe two more devnets?), would then remove this DFI list and this would also remove this "sentiment" from the canonical fork Meta:

As I understand it, most PFIs that progress to DFI will still be in Draft status. In practice, there will likely be at least one DFI EIP in Draft at any given time. If we want to promote the Upgrade Meta EIP to Review, removing the DFI section at that stage makes sense, unless the proposed backticks approach is supported by the bot.

However the EIP also states this:

In exceptional circumstances, client developers MAY choose to move an EIP from Declined for Inclusion to Considered for Inclusion or Scheduled for Inclusion.

So a DFId EIP is not a guarantee that it does not go in this fork, although it is a strong one.

I would consider this a truly "exceptional case". As per the statement, if an EIP is moved back into the upgrade inclusion stages, it would re-enter at CFI or SFI rather than PFI, which implies it would already be at least in Review status. As a result, it should not block the promotion of the Upgrade Meta EIP.

My feeling is that it is the point to move the EIP to "Review" once we are in the "final devnet" stage, this would remove the DFId EIPs, but it would create some uncomfortable ambiguity about what this Review status is/signals. I feel like we should make this clear. If a DFId EIP is later re-proposed then via git history we can signal/verify that the EIP was DFId before (but this is not super elegant).

I also think Review should generally represent a more mature stage thanDraft, and therefore typically have a longer tenure. Moving the Upgrade Meta EIP to Review at the beginning of the devnet phase gives client teams, enterprises, and the broader community sufficient time to thoroughly review the upgrade while signaling that the proposal has reached a more stable stage than Draft, encouraging more focused feedback.